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ABSTRACT 


'The  Mass  Store  system  is  used  to  store  a  large  number 
of  user  files.  Users  store  files  on  Mass  Store  from 
the  NOS/BE  machines. 

The  idea  behind  storage  on  Mass  Store  is  that  a  large 
amount  of  information  can  be  saved  on  Mass  Store  with 
no  worries  of  reaching  full  disk  capacity.  Files  that 
have  not  been  accessed  recently  are  written  to  car¬ 
tridge  and  the  disk  space  is  released.  Also,  there  is 
no  limit  to  how  long  a  file  can  exist;  a  file  will  not 
be  purged  due  to  lack  of  use. 

This  document  is  a  presentation  of  a  locally  designed 
procedure  that  ensures  that  each  file  stored  on  Mass 
Store  is  also  backed  up  by  Mass  Store.  This  procedure 
replaces  the  previous  method  which  used  standard  nine- 
track  tapes  as  the  backup  media.  . 

'  r  /  ,,  ,  7/ 
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GENERAL  DESCRIPTION  OF  MASS  STORE 


The  Mass  Storage  Subsystem  (MSS)  at  DTNSRDC  is  driven 
by  a  Cyber  825  machine  running  NOS  (Network  Operating 
System).  Two  CDC  NOS/BE  machines,  the  CYBER  176  and  the 
CYBER  750,  are  linked  to  the  825  by  satellite 
couplers.  By  using  these  couplers,  users  can  store 
and  fetch  files  from  MSS.  The  files  that  are  sent  to 
MSS  are  initially  stored  on  disk.  Eventaully,  a  file 
will  be  written  to  cartridge.  If  that  file  has  not 
been  accessed  recently,  it  will  be  released  from  disk. 
Once  a  file  resides  on  cartridge  only,  it  can  still  be 
fetched  by  the  user.  The  file  is  staged;  i.e.,  the 
file  is  read  from  the  cartridge  and  written  to  disk. 

The  equipment  that  houses  cartridges  is  called  a  Car¬ 
tridge  Storage  Unit  (CSU) .  At  the  time  of  this  docu¬ 
ment,  DTNSRDC  has  six  CSU's.  Each  CSU  has  two  Mass 
Storage  Transports  (MST's).  An  MST  reads  from  and 
writes  to  cartridges. 


2 


«\  *.  -  o 


THE  OLD  METHOD  —  A  GENERAL  OVERVIEW 


The  previous  method  of  backing  up  files  on  Mass  Store 
was  to  dump  files  to  tape.  One  night  a  week,  every 
file  on  the  system,  whether  on  disk  or  cartridge,  was 
dumped  to  tape.  All  files  residing  on  cartridge  were 
staged  and  copied  to  dump  tapes.  On  the  other  nights, 
files  that  had  been  changed  since  the  last  dump  were 
dumped  to  tape. 

One  problem  with  this  method  of  backing  up  files  was 
the  lack  of  efficiency.  Each  file  on  MSS  was  dumped  to 
tape  weekly,  regardless  of  when  the  file  was  modified. 
Since  unused  files  were  not  being  purged  periodically, 
the  total  number  of  files  on  MSS  was  growing  larger. 
Therefore,  the  amount  of  time  and  the  number  of  tapes 
it  took  to  complete  the  procedure  was  intolerable.  The 
procedure  was  employing  approximately  50  tapes  and  took 
as  long  as  20  hours. 

A  lengthy  dump  caused  a  few  problems.  If  a  dump  ran 
over  into  production  time,  users  needing  files  on  Mass 
Store  would  be  affected;  the  request  for  a  file  was 
competing  with  the  dump  for  MSS  processing. 

Control  Data  Customer  Engineers  (CE's)  were  also 
affected.  They  lost  preventive  maintenance  time. 


THE  NEW  METHOD  —  AN  OVERVIEW 


A  new  dump  procedure  that  reduced  both  the  number  of 
files  dumped  and  the  number  of  tapes  needed  to  retain  a 
full  backup  of  the  files  on  MSS  was  highly  desirable. 
This  new  procedure  was  designed  and  implemented  in  June 
1983. 

For  the  new  version  of  the  backup  procedure,  there  are 
two  concepts  of  backing  up  files.  First,  every  file 
that  has  been  modified  since  the  last  time  the  pro¬ 
cedure  was  run  is  dumped  to  a  "backup"  cartridge  on 
Mass  Store.  This  creates  a  second  copy  of  each  file  on 
an  alternate,  or  backup,  family.  Every  file  that 
resides  on  disk  is  copied  to  dump  tapes.  In  addition, 
the  permanent  file  catalog  (PFC)  of  every  file  that 
resides  on  disk,  MSF,  or  in  both  places  is  copied  to 
dump  tapes.  This  involves  no  staging  of  files. 

The  new  backup  procedure  is  much  more  efficient  than 
the  previous  one.  A  file  is  dumped  to  tape  depending 
upon  where  it  resides  on  Mass  Store.  If  a  file  resides 
on  disk  only,  it  is  dumped;  however,  if  a  file  resides 
on  MSF  at  all,  just  its  PFC  is  dumped.  This  reduces 
the  number  of  tapes  for  a  permanent  file  dump  to 
approximately  one  or  two  and  the  number  of  hours  to 
six.  The  same  procedure  is  run  every  night.  Because 
the  dump  rarely  runs  into  production  time,  there  is 
less  interference  to  the  users.  Also,  there  is  now 
adequate  preventive  maintenance  time  for  the  CDC  CE's. 

Another  nice  feature  of  the  new  procedure  is  that  if  a 
permanent  file  disk  crashes,  the  whole  sytem  can  be 
reloaded  from  just  one  set  of  tapes.  (This  is 
explained  more  thoroughly  later  in  this  document.) 

As  stated  before,  this  procedure  causes  two  copies  of  a 
file  to  be  created.  Therefore,  if  one  of  those  files 
becomes  bad,  the  other  can  be  used  to  restore  it.  No 
tapes  would  be  involved  in  the  restoration. 


PREPARATIONS  FOR  IMPLEMENTATION 


In  preparation  of  the  iapleaentation  of  the  new  aethod 
of  backing  up  files  on  Mass  Store,  certain  changes  had 
been  Bade  to  the  MSS  configuration.  A  new  faaily, 
BACKFAM,  was  defined  on  the  NOS  systea.  All  backup 
files  reside  in  this  faaily.  The  logical  devices 
included  in  this  faaily  are  two  CSU's  (C  and  D)  and  one 
full-track  disk  drive. 

All  the  files  that  currently  resided  on  the  systea  were 
duaped  to  BACKFAM.  This  ensured  that  every  file  had  a 
backup  copy. 


PERMANENT  FILE  BACKUP  PROCEDURE  ALGORITHM 
(program  related  to  each  step  in  parens) 


A.  Backup  special  MSS  system  files 

B.  If  legal  user  index  range  specified 

continue 

else 

abort 


C.  If  restart  requested  then 

if  restart  file  exists  then 
continue 
else 
abort 

else 

if  restart  file  exists  then 
if  restart  desired 
drop  job 
else 

continue 

else 

continue 


D.  If  initial  call  for  daily  permanent  file  dump  then 

copy  files  created  that  day  on  the  production  family  to 
cartridge  (MOVE) 

release  disk  space  in  production  family  of  files  not  accessed 
in  four  days  (MOVE) 

release  cartridge  space  in  production  family  (RELRDFS) 
else 

continue 


E.  Save  system  date  and  time  (SAVDATE) 

F.  Perform  audit  to  obtain  an  unsorted  list  of  users  who 
have  created  or  modified  files  since  the  last  dump 
(AUDIT) 

G.  Sort  user  list  (SORTUIS) 
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H.  For  each  user  in  user  list 

1.  set  user  index 

2.  perform  catlist 

3.  perform  PFCAT  for  indirect  access  files  (PFCATS) 

A.  perform  PFCAT  for  direct  access  files  (PFCATS) 

5.  perform  one  PFDUMP  to  BACKFAM  for  all  indirect  access  files 

(I BACKUP) 

6.  perform  one  PFDUMP  to  BACKFAM  for  each  direct  access  file  (DBACKUP) 

7.  set  family  to  BACKFAM 

8.  perform  catlist 

9.  for  each  file  in  production  family  catlist  (COMPARE) 
a.  if  not  in  BACKFAM  then 

perform  PFDUMP  to  BACKFAM 

10.  for  each  file  in  BACKFAM  catlist  (COMPARE) 
a.  if  not  in  production  family  then 

purge  file  in  BACKFAM 

11.  move  files  from  disk  in  BACKFAM  to  cartridge  in  BACKFAM  (COMPARE) 

12.  set  family  to  production  family 


I.  Dump  BACKFAM  PFC's  to  tape  and  create  RDF  for  BACKFAM 
(MSS1MGA) 

J.  Release  cartridge  space  in  BACKFAM  (MSSIMGA) 

K.  For  every  file  in  production  family  (MSSIMGA) 

if  file  resides  on  disk  alone  then 
dump  to  tape 

elseif  file  resides  on  MSF  alone  then 
dump  PFC's  to  tape 

elseif  file  resides  on  both  disk  and  MSF  then 
dump  PFC's  to  tape 


L.  Create  RDF  for  production  family  (MSSIMGA) 

M.  If  restart  file  exists  then 

purge  it 


ERROR  EXIT  PROCESSING 

A.  Save  user  index  being  processed  at  time  of  exit,  the 
last  user  index  to  be  processed,  and  the  remaining 
parameters  as  requested  in  the  initial  call  (ERROR) 
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PROGRAMS,  PROCEDURES,  AND  SPECIAL  FILES 


The  procedure  references  other  procedures  and  FORTRAN  V 
programs.  Each  program  creates  small  procedures  and/or 
data  files  to  be  used  by  another  program.  Furthermore, 
special  files  are  created  and  saved  by  the  main  pro¬ 
cedure  so  that  they  can  supply  initial  parameters  if  so 
desired. 


FORTRAN  V  PROGRAMS 
REINIT 

— used  if  the  procedure  is  restarted 

— reinitializes  the  parameters  of  the  procedure  so  that  it  may  begin 
where  it  left  off 

— input  is  the  restart  file  REINSTS 

— output  is  the  files  TAPE30,  TAPE40,  TAPE50,  and  TAPE60  containing  the 
input  parameters  that  were  saved  during  error  exit  processing 


SAVDATE 

— saves  the  system  date  and  time  the  procedure  begins 
— input  is  the  date  and  time  obtained  from  the  operating  system 
—  output  is  the  file  DATTIM  containing  the  system  date  and  time*,  if 
the  procedure  is  the  initial  call  of  the  daily  dump  procedure  coming 
to  an  end,  this  file  is  saved  as  DMPDATE  to  determine  the  default  AD 
and  AT  parameters  for  the  next  day's  dump  procedure 


MOVE 

— used  if  the  initial  run  of  the  day's  dump 

— creates  the  procedure  MOVPROC  that  performs  an  ASMOVE  that  releases 
files  from  disk  and  moves  them  to  cartridge  if  they  have  not  been 
accessed  in  four  days 

—  input  is  the  file  DATTIM  and  the  file  TAPE60  containing  the  family 
being  processed 

— output  is  the  procedure  MOVPROC 


AUDCAT 

— creates  the  procedure  AUDCAT  that  performs  PFCAT's  for  the  production 
family 

—  input  is  the  file  DMPDATE  and  the  file  TAPE40  containing  the  date  and 
time  obtained  from  the  procedure  call 
— output  is  the  procedure  AUDCAT 


RELRDFS 


— used  if  the  initial  run  of  the  day's  dump 

— creates  the  procedure  RDFPROC  that  performs  an  ASVAL  on  the  produc¬ 
tion  family  using  RDF's  (release  data  file)  from  a  month  and  one  week 
ago  until  a  month  ago  (if  they  exist);  the  RDF's  are  then  purged 
— input  is  the  file  DATUM  and  the  file  TAPE60  containing  the  family 
being  processed 

— output  is  the  procedure  RDFPROC 


SORTUIS 

— sorts  the  list  of  users  in  numeric  order 

— input  is  the  file  MARY  containing  the  unsorted  list  of  user  indices; 
MARY  is  created  by  the  normal  audit  procedure  that  uses  the  output 
from  the  procedure  AUDCAT  as  input 

— output  is  the  file  TAPE2  containing  the  sorted  list  of  user  indices 


BACKUP 

— sets  up  the  files  used  by  the  DMPROC  procedure  using  the  input 
parameters  from  the  initial  call 

— input  is  the  files  TAPE30  containing  the  user  index  range,  TAPE40 
containing  the  date  and  time  of  the  previous  dump,  TAPE50  containing 
the  permanent  file  (if  any),  TAPE60  containing  the  family  being 
processed  and  TAPE2  containing  the  sorted  list  of  user  indices 
— -output  is  the  file  INDXLST  containing  the  sorted  list  of  user  indices 
beginning  and  ending  within  the  range  specified,  the  file  LAST 
containing  the  last  user  index  to  be  processed,  the  file  DATELST 
containing  the  date  and  time  to  be  processed,  and  the  procedure  DUMP 
that  processes  the  user  indices 


PFCATS 

— creates  the  procedure  PFCPROC  that  sets  the  user  index  to  be  pro¬ 
cessed  and  performs  a  catlist  and  PFCAT's  for  indirect  and  direct 
access  file;  saves  the  next  user  index  to  be  processed 
—input  is  the  files  INDXLST,  TAPE40,  TAPE50,  and  TAPE60 
— output  is  the  procedure  PFCPROC,  the  file  NEXT  containing  the  next 
user  index  to  be  processed,  and  the  file  NOW  containing  the  user 
index  currently  being  processed 


IBACKUP 


— creates  the  procedure  IPROC  to  perforin  a  PFDUMP  for  a  user's  indirect 
access  files 

— input  is  the  output  for  the  PFCAT  of  the  indirect  access  files 
— output  is  the  procedure  IPROC 


DBACKUP 

— creates  the  procedure  DPROC  to  perform  PFDUMP's  for  a  user's  direct 
access  files 

— input  is  the  output  for  the  PFCAT  of  the  direct  acess  files 
— output  is  the  procedure  DPROC  and  the  file  NODUMP  containing  the 
files  with  the  backup  requirement  of  no  or  media  dependent 


COMPARE 

— compares  the  catlist  output  of  the  user's  files  in  the  production 
family  with  the  corresponding  catlist  output  in  BACKFAM  and  creates 
the  procedure  CMPPROC  that  purges  and  dumps  files  accordingly  (if  a 
file  in  the  production  family  but  not  in  BACKFAM,  it  is  dumped  to 
BACKFAM;  if  a  file  is  in  BACKFAM  but  not  in  the  production  family,  it 
is  purged  in  BACKFAM)  and  performs  an  ASMOVE  on  the  user  in  BACKFAM 
— input  is  the  files  FCATLST  and  BCATLST  containing  the  catlist  outputs 
for  the  production  family  and  BACKFAM  respectively,  the  file  NODUMP, 
and  the  file  NOW 

— output  is  the  procedure  CMPPROC 


MSSIMGA 

— creates  the  procedure  IMGPROC  that  performs  PFDUMP's  of  BACKFAM  and 
the  production  family  to  tape  and  an  ASVAL  on  BACKFAM  with  an  RDF 
that  was  created  during  the  last  time  the  procedure  was  run 
—  input  is  the  file  DATUM 
— output  is  the  procedure  IMGPROC 


ERROR 


— used  if  the  procedure  aborts  prematurely 

— saves  all  the  parameters  needed  to  reinitialize  the  procedure 
— input  is  the  file  NOW,  the  file  LAST,  the  file  DATELST,  and  the  files 
TAPE50  and  TAPE60 

— output  is  the  file  REINSTS  containing  the  range  of  indices  that  still 
need  to  be  processed,  the  date  and  time,  the  permanent  file  (if  any), 
and  the  family  that  was  being  processed 


PROCEDURES 

AUDIT 

— creates  the  file  MARY  containing  the  unsorted  list  of  user  indices 


DMPROC 

— used  for  each  user  in  the  file  INDXLST 

— for  each  user  index  executes  the  FORTRAN  V  programs  PFCATS,  IBACKUP, 
DBACKUP,  and  COMPARE  for  the  family  specified  by  the  FM  parameter 


SPECIAL  FILES 
DMPDATE 

— contains  the  date  and  time  of  the  last  time  the  procedure  was  called 
using  UI**ALL 

— format:  (beginning  in  column  1) 

YYMMDD  (date) 

HHMMSS  (time) 


REINSTS 

— restart  file 

— contains  the  parameters  needed  to  restart  the  procedure  if  it  had 
ended  prematurely 
—  format:  (beginning  in  column  1) 

UI-LUI  (beginning  and  ending  user  index,  one-to-six  digits) 
AD  (after  date,  YYMMHH) 

AT  (after  time,  HHMMSS) 

PF  (permanent  file  name,  seven  alphanumeric  characters) 

FM  (family,  seven  alphanumeric  characters) 


>  -■-  >  V-. 
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DESCRIPTION  OF  CONTROL  PARAMETERS 


The  procedure  accepts  parameters  to  precisely  con¬ 
trol  which  files  are  to  be  processed.  Seven  paraa¬ 
eters  are  allowed  when  invoking  the  procedure.  The 
parameters  are  specified  in  keyword  format.  The 
call  statement  is 

X. INCDMP (UI“ui , LUI“lui , AD-yymmdd , AT“hhmmss ,  PF-f ilename, 
FM-family,RESTART«no/yes) 


KEYWORD  OPTION 

UI  -  ALL 

ui 
uil 

LUI  -  0 

lui 

AD  •  yymmdd 

AT  ”  hhmms  s 

PF  *  filename 

FM  *  family 

RESTART  -  yes 

no 


DESCRIPTION 

Process  all  user  indices  in  index  list.  (Default) 
Process  single  user  index. 

Process  range  of  user  indices  beginning  with 
uil. 

No  last  user  index.  Used  if  UI*ALL  or  UI**ui. 
(Default) 

Process  range  of  user  indices  ending  with  lui. 

Date  in  6'digit  format  of  year,  month,  day.  Files 
created  or  modified  after  this  date  are  to  be 
processed.  (Default-date  of  last  permanent  file 
dump  saved  in  file  DMPDATE) 

Time  in  6-digit  format  of  hour,  minute,  second. 

Files  meeting  the  AD-yynnndd  criterion  and  created 
after  this  time  are  to  be  processed.  (Default¬ 
time  of  last  permanent  file  dump  saved  in  file 
DMPDATE) 

Name  of  permanent  file  to  be  processed.  If  the  PF 
parameter  is  specified,  then  the  UI  parameter  must 
also  be  specified  for  a  single  user.  (No  default; 
not  a  required  parameter) 

Name  of  family  to  be  processed.  (Default~SYST75) 

The  procedure  had  ended  prematurely  and  needs  to 
be  restarted  where  it  left  off.  All  the  information 
needed  is  contained  in  the  file  REINSTS. 

This  is  an  initial  call  to  the  procedure.  (Default) 


HOW  IS  THE  PROCEDURE  ACTUALLY  IMPLEMENTED? 


The  backup  procedure  is  invoked  by  entering  the  eonmand 
at  the  conaole.  By  supplying  a  combination  of  parame¬ 
ters  ,  the  procedure  can  be  used  in  a  number  of  dif¬ 
ferent  ways. 


X.INCDMP. 

The  operator  begins  the  daily  permanent  file  dump  by 
entering  the  above  comsiand.  The  default  parameters  are 
used. 


X.INCDMP (UI«ui) 

All  this  user's  files  that  have  been  created  or  modi¬ 
fied  since  the  last  permanent  file  dump  will  be  dumped 
to  BACKFAM. 


X. INCDMP (Ul-ui 1 , LUI-lui) 

All  the  files  for  all  the  users  whose  user  index  lies 
within  the  range  uil  and  lui  that  have  been  created  or 
modified  since  the  last  permanent  file  dump  will  be 
dumped  to  BACKFAM. 


X.INCDMP (UI-ui ,PF”f ilename) 

The  permanent  file  "filename"  under  this  user  will  be 
dumped  to  BACKFAM.  Any  AD  or  AT  parameters  will  be 
ignored. 


Using  the  FM  parameter 

Files  on  the  family  specified  will  be  processed. 


Using  the  AD  and  AT  parameters 


The  information  on  the  file  DMPDATE  is  ignored  and  the 
date  and  the  time  specified  on  the  procedure  call  will 
be  used.  Files  created  or  modified  after  this  date  and 
time  will  be  processed. 


X. INCDMP (RESTART-YES) 

This  option  assumes  that  the  restart  file  REINSTS 
exists.  The  procedure  will  use  the  information  on  this 
file  as  input  parameters.  Any  other  parameters  given 
when  "RESTART- YES"  is  entered  are  ignored.  If  REINSTS 
does  not  exist,  a  dayfile  message  stating  that  there  is 
no  restart  file  is  displayed  and  the  procedure  ter¬ 
minates.  If  REINSTS  does  exist  but  this  option  was  not 
chosen,  a  dayfile  message  is  displayed  giving  the 
operator  an  option  to  either  continue  the  procedure  or 
drop  it  and  begin  again  with  "RESTART-YES".  If  he/she 
chooses  to  continue  and  the  procedure  ends  prematurely, 
the  current  version  of  REINSTS  will  be  replaced  by  a 
L  new  one. 


POSSIBLE  PROBLEMS 


Sometimes  the  procedure  may  terminate  prematurely. 
This  can  occur  because  of  either  a  software  or  hardware 
problem,  or  the  operator  dropped  the  job  for  some  rea¬ 
son.  In  a  case  like  this,  the  operator  can  reinitial¬ 
ize  the  job  by  entering  the  "RESTART*YES"  option. 

However,  there  are  a  few  instances  when  the  file 
REINSTS  will  not  be  saved.  For  example,  if  there  is  a 
power  outage  while  the  procedure  is  running,  obviously 
the  error  exit  processing  will  not  be  performed.  So 
when  the  operator  tries  to  reinitialize  the  job  by 
entering  the  "RESTART“YES"  option,  a  dayfile  message 
will  appear  informing  him/her  that  REINSTS  does  not 
exist  and  to  enter  the  procedure  REDUMP. 

REDUMP  is  a  system  procedure  that  the  operator  enters 
when  there  is  no  restart  file.  REDUMP  checks  the  day- 
file  to  determine  what  user  was  being  processed  when 
the  system  went  down. 

The  worst  problem  concerning  the  daily  permanent  file 
dump  occurs  when  a  user  creates  or  modifies  so  much 
information  that  the  disk  assigned  to  BACKFAM  runs  out 
of  space.  A  message  flashes  at  the  console  informing 
the  operator  that  the  device  for  BACKFAM  is  full.  The 
operator  then  drops  the  job  and  enters  the  system  pro¬ 
cedure  MOVE  which  performs  an  ASMOVE  for  BACKFAM  When 
this  procedure  finishes,  the  dump  can  be  restarted. 
However,  it  is  not  desirable  to  use  the  "RESTART" YES" 
option  because  the  procedure  would  start  with  the  very 
same  user  that  caused  the  problem  in  the  first  place. 
The  operator  must  enter  the  procedure  with  the  follow¬ 
ing  parameters:  1)  UI*the  next  user  index;  2) 
LUI-377777  (the  last  user  index);  3)  AD*the  date  of  the 
last  dump;  and  4)  AT- the  approximate  time  of  the  last 
dump  (160000  is  usually  entered).  The  procedure  would 
then  begin  with  the  user  index  following  the  user  who 
had  filled  the  disk  space. 

To  complete  the  dumping  of  that  user's  files,  a  system 
analyst  is  needed.  It  is  possible  for  the  analyst  to 
determine  what  was  the  last  file  that  the  job  had 
dumped  and  continue  with  the  rest  of  the  user's  files. 


THE  ADVANTAGES  OF  USING  THIS  PROCEDURE 


Many  things  can  happen  in  the  every  day  use  of  the  Mass 
Store  software  and  hardware  that  will  cause  problems 
that  can  be  solved  semi-easily  because  this  procedure 
is  in  production. 

Daily  reports  are  run  that  inform  the  system  analyst 
what  files  have  been  flagged  with  an  error.  Sometimes, 
depending  on  the  error,  it  is  impossible  for  the  user 
to  attach  that  file.  The  analyst  can  clear  the  flag 
and  attempt  to  reattach  the  file.  If  this  attempt 
fails  again,  the  archive  copy  of  this  file  can  be 
reloaded  from  BACKFAM  to  the  production  family  using  a 
locally  designed  maintenance  procedure  called  RELOAD. 
If  for  some  reason  the  archive  file  on  BACKFAM  is  bad, 
its  PFC  may  be  reloaded  using  the  previous  night's 
tapes  containing  BACKFAM  PFC's.  Then  RELOAD  can  be 
used. 

If  the  reports  reveal  that  a  file  cannot  be  attached 
because  of  a  missing  cartridge,  the  file  can  be 
restored  using  RELOAD. 

If,  for  some  reason,  a  permanent  file  disk  for  the  pro¬ 
duction  family  is  lost,  the  files  on  this  disk  can  be 
reloaded  using  the  production  family  dump  tapes. 
Because  a  full  permanent  file  dump  is  performed  every 
night,  only  the  previous  night's  permanent  file  dump 
tapes  are  needed  to  reload  the  disk. 

If  a  user  accidently  purges  a  file,  that  file  can  be 
reloaded  if  User  Services  is  informed  within  30  days. 
The  file  will  be  reloaded  from  the  last  set  of  dump 
tapes  that  the  file  was  on.  If  30  days  have  passed, 
the  space  on  which  this  file  resided  on  cartridge  would 
have  been  released  and,  at  this  time,  the  file  can  not 
be  reloaded. 
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The  following  ter 
procedure: 

archive  file — a  f 
backup  file  fo 


release  data  file  (RDF) — file  created  during  the  dump  identifying  files 
residing  on  cartridge  that  are  pointed  to  by  a  permanent  file  catalog 
entry;  files  that  have  been  purged  but  are  still  on  the  system  do 
not  have  permanent  file  catalogs.  This  file  will  be  used  in  a  future 
dump  by  ASVAL  to  release  files  from  MSF  that  no  longer  have  PFC's 
(i.e.,  the  files  have  been  purged). 

stage — to  copy  a  direct  access  file  from  MSF  to  disk. 

user  index — a  one~to~six-digit  octal  number  that  is  associated  with  a 
particular  user;  there  is  a  one-to-one  correspondence  between  a  user 
and  a  user  index. 


Permanent  File  Utilities  Used: 

PFCAT — produces  a  catalogued  directory  of  file  information. 

PFDUMP — dumps  files  from  a  permanent  file  device  to  backup  files. 


MSS  Utilities  Used: 

ASMOVE — destages  disk  files  to  MSF  and  releases  disk  space. 
ASVAL — releases  cartridge  space  of  files  that  have  been  purged. 


NOTE — The  above  information  was  obtained  from  NOS  2  SYSTEM  MAINTENANCE 
REFERENCE  MANUAL,  rev.  C,  pages  1-1 , 3,9, 19,35 , 48;3-l ,2,  and  NOS  2 
REFERENCE  SET  VOL.  3,  rev.  C,  page  2-14. 


DTNSRDC  ISSUES  THREE  TYPES  OF  REPORTS 

1.  DTNSRDC  REPORTS,  A  FORMAL  SERIES,  CONTAIN  INFORMATION  OF  PERMANENT  TECH¬ 
NICAL  VALUE.  THEY  CARRY  A  CONSECUTIVE  NUMERICAL  IDENTIFICATION  REGARDLESS  OF 
THEIR  CLASSIFICATION  OR  THE  ORIGINATING  DEPARTMENT. 

2.  DEPARTMENTAL  REPORTS.  A  SEMIFORMAL  SERIES,  CONTAIN  INFORMATION  OF  A  PRELIM¬ 
INARY.  TEMPORARY,  OR  PROPRIETARY  NATURE  OR  OF  LIMITED  INTEREST  OR  SIGNIFICANCE. 
THEY  CARRY  A  DEPARTMENTAL  ALPHANUMERICAL  IDENTIFICATION. 

3.  TECHNICAL  MEMORANDA.  AN  INFORMAL  SERIES.  CONTAIN  TECHNICAL  DOCUMENTATION 
OF  LIMITED  USE  AND  INTEREST.  THEY  ARE  PRIMARILY  WORKING  PAPERS  INTENDED  FOR  IN¬ 
TERNAL  USE.  THEY  CARRY  AN  IDENTIFYING  NUMBER  WHICH  INDICATES  THEIR  TYPE  AND  THE 
NUMERICAL  CODE  OF  THE  ORIGINATING  DEPARTMENT.  ANY  DISTRIBUTION  OUTSIDE  DTNSRDC 
MUST  BE  APPROVED  BY  THE  HEAD  OF  THE  ORIGINATING  DEPARTMENT  ON  A  CASE-BY-CASE 


